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Amendments to the Drawings: 

Please replace the sheet of drawings with Figures 3-5 with the attached Replacement Sheet 2. 
Only Figure 5 has been modified as described in the Remarks section of this paper. 



Attachments: Replacement Sheet 2 (Figures 3-5) 
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REMARKS 

Claims 1-14 are pending. No amendments have been made with this paper. Thus, upon 
entry of this Response, claim 1-14 remain pending. 

The Objection to the Drawings 

The drawings were objected to under 37 C.F.R. §1.84(p)(4) because reference identifier 
"118" was used to designate both "OEN" and "QED" in Figure 5. Figure 5 has been amended to 
correct the designation of "QED" D-type register 222 (previously inadvertently identified by 
reference identifier "1 1 8") such that it is labeled by the same reference identifier "222" as in the host 
interface device illustrated in Figure 2 and upon which Figure 5 is based. See, for example, 
Paragraphs 00 1 5 and 0028-0029 of the originally filed application for support for this modification. 
It is respectfully submitted that this modification and resubmission of Figure 5 overcomes the 
objection. Withdrawal thereof is respectfully requested. 

The 35 U.S.C. §102 Rejection 

Claims 1-13 were rejected under 35 U.S.C. §102(e) as being anticipated by Tamagno et al 
(U.S. Patent Publication No. 2004/0215471 Al). This rejection is respectfully traversed and 
withdrawal thereof is requested. 

Claim 1 recites: 

A method of effecting a substitute for a data communication target protocol in 
communications between a host interface device and a client interface device, the method 
comprising: 

a) selecting a first protocol that is supported by the client, such that a first 
predetermined data and control signal sequence conveyed to the client from the host 
predictably elicits a response from the client that accords with the supported protocol, 
wherein the predetermined data and control signal sequence is initiated by the host to invoke 
the supported protocol; 

b) selecting a different second protocol that is unsupported by the client in that the host 
does not have access to a unique data and control sequence that will predictably elicit a 
response, required by such unsupported protocol, when conveyed from the host to the client; 

c) determining a need for invocation of the second protocol to effect a particular 
function in the host that is not explicitly effected by the supported protocol; 
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d) conveying the first predetermined data and control signal sequence from the host to 
the client; 

e) receiving a response to the host from the client that accords with the supported 
protocol; and 

f) interpreting the response, within the host, to approximately effect the particular 
function in the host. 

Claims 2-7 depend, directly or indirectly, from claim 1 . 

Claim 8 recites: 

A host interface device apparatus for controlling data transfers between the host interface 
device and a client interface device, comprising: 

a) host logic configured to cause transmission to the client of a control data sequence 
predetermined to invoke a first data communication protocol response from the client; 

b) a triggering host signal indicating a need for invocation of a different second data 
communication protocol from the client; and 

c) host logic configured to cause transmission to the client of the predetermined data 
sequence to invoke the first data communication protocol response from the client in 
response to both of 

i) a host need to invoke the first protocol, and 

ii) the triggering host signal for the second protocol in an absence of (c)(i). 

Claims 9-13 ultimately depend from claim 8. 

Tamagno et al do not teach each and every element of these rejected claims. This is not 
surprising given the substantial differences between the limited focus of Tamagno et al and the 
present invention. 

Tamagno et al describe a smart card device and a method for debug and software 
development related to the same. Tamagno et al describe the benefits of their apparatus and 
methods with reference to the fact that they provide "a smart card device that can be debugged and 
software developed in a secure manner without requiring additional pins or contacts than are 
normally used." (Para. 0017) This was deemed noteworthy as for "cost and security, smart cards 
typically only support a USB port without any ISO 7816 interface operating simultaneously . . . 
[resulting in] no means to debug and encode/decode software running in the smart card memory 
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using only one port." (Para. 0016) In that regard, taking advantage of the multiple pipe capabilities 
of USB protocol, Tamagno et al utilize an interface defined by a plurality of communication pipes 
and respective endpoints, including one interrupt endpoint that can be configured to function as a 
debug port for debugging and software development using a debug monitor program. (Paras. 0019- 
0020) A smart card operating in a USB mode is described throughout Tamagno et al By making 
use of the multiple pipe capabilities of the USB protocol, a USB smart card is taught to have a single 
port that is capable for use in both communicating and operation as well as debugging. (Para. 0033) 

In order to effectuate a debugger program on the smart card the "host communicates with the 
physical device using a desired communication that is designed to match any communication 
requirements of the physical device and transfer characteristics provided by a USB." (Para. 0042) 
The debugging port configured by the personal computer is the same as the primary port used for 
communication and operation - it is a USB port that "makes use of the multiple pipe capabilities of 
the USB protocol." (Para. 0033) 

The Examiner makes repeated reference to Para. 0012 of Tamagno et al Para. 0012 of 
Tamagno et al states: "Two protocols are involved in supporting transactions between the smart 
card and host computer. The first protocol complies with the ISO-78 1 6-3, which provides detailed 
requirements for the serial interface between smart card and smart card reader. The reader is 
connected to the computer via a serial port, a parallel port, or the Universal Serial Port (USB), using 
a second protocol." When the "smart card is inserted into a smart card reader connected to a host 
computer[,] . . . communication between the smart card [and the smart card reader] using the first 
protocol and the host computer [and the smart card reader] using the second protocol" occurs. 

Applicants respectfully submit that the description set forth in Para. 0012 of Tamagno et al 

does not support the Examiner's rejection of the pending claims. Rather, Para. 0012 of Tamagno et 

al describes use of two protocols for communicating between three devices (i.e. 9 a smart card, a 

smart card reader, and a personal computer) - one protocol for communications between the smart 

card and smart card reader and the other protocol for communications between the smart card reader 

and the personal computer. In stark contrast, pending Claims 1-13 are directed toward a method 

(Claims 1-7) and an apparatus (Claims 8-13) that uses two different protocols to communicate 
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between two devices. Tamagno et al do not teach or suggest presently claimed methods and 
apparatus that enable a host interface device to effectively implement a data communication protocol 
feature, such as, for example, flow control, with respect to data transfers from a client interface 
device that does not explicitly support such protocol feature. 

For the sake of argument, and consistent with the Examiner's apparent interpretation of 
Tamagno et al, assume that a smart card is synonymous with a "client" and a personal computer is 
synonymous with a "host" as recited in the presently rejected claims. Similarly assume that the "first 
protocol that is supported by the client" is that for communication between the smart card and the 
smart card reader and which "complies with the ISO-7816-3." (Page 4 of the Office Action and 
Para. 00 1 2 of Tamagno et al ) Similarly assume that the "second protocol that is unsupported by the 
client" is the protocol for communication between the personal computer and the smart card reader, 
which is exemplified as being associated with a USB connection. (Page 4 of the Office Action and 
Para. 0012 of Tamagno et al) Finally assume that "debugging" is the "particular function" referred 
to in Applicants 1 claims. (Page 5 of the Office Action) Based on these assumptions, reference is 
made to specific steps recited in claim 1. 

With these assumptions, referring to Tamagno et al, step (c) would read similar to the 
following: determining a need for invocation of the protocol for communication between the 
personal computer and the smart card reader to effect debugging in the personal computer that is not 
explicitly effected by the protocol for communication between the personal computer and the smart 
card reader. Similarly, step (f) would read: interpreting the response, within the personal computer, 
to approximately effect the debugging in the personal computer. Tamagno et al do not teach or 
suggest these recited steps. It is particularly noteworthy that the debugging described throughout 
Tamagno et al occurs in the smart card, not the personal computer. (See, for example, Para. 0016 of 
Tamagno et al) In contrast, an exemplary application of the method and apparatus defined by 
Applicants claims is that where flow control is provided in the host . 

Tamagno et al do not teach or suggest the presently claimed methods and apparatus that 

enable a host interface device to effectively implement a data communication protocol feature, such 

as, for example, flow control, with respect to data transfers from a client interface device that does 
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not explicitly support such protocol feature. As noted in Paras. 008 and 009 of Applicants' 
specification, a different protocol feature that is supported by the client may be invoked in such a 
way as to cause an effect that is substantially the same as would be provided by invocation of the 
unsupported protocol. This effect can be obtained even though the data communication protocol 
feature is unsupported by the client. Tamagno et ah is completely silent in this regard. 

Due to the substantial differences between Tamagno et ah and presently pending claim 1, 
some of which are described above, withdrawal of this rejection is respectfully requested with 
respect to claim 1 and claims 2-7 due to their direct or indirect dependency from claim 1. 

Tamagno et ah similarly do not teach each and every step of rejected claims 8-13. Claim 8 
recites an "apparatus for controlling data transfers between the host interface device and a client 
interface device." Recited therein are a "first data communication protocol" and a "different second 
data communication protocol" for communications between a host and client. Thus, claim 8 is 
directed toward communication between one pair of devices using two different protocols and host 
logic associated with the same. Tamagno et ah do not teach or suggest such apparatus. Rather, 
Tamagno et ah discuss use of two protocols for communicating between three devices (i.e., a smart 
card, a smart card reader, and a personal computer) - one protocol for communications between the 
smart card and smart card reader and the other protocol for communications between the smart card 
reader and the personal computer. 

Again, Tamagno et ah do not teach or suggest presently claimed methods and apparatus that 
enable a host interface device to effectively implement a data communication protocol feature, such 
as, for example, flow control, with respect to data transfers from a client interface device that does 
not explicitly support such protocol feature. As noted in Paras. 008 and 009 of the present 
specification, a different protocol feature that is supported by the client may be invoked in such a 
way as to cause an effect that is substantially the same as would be provided by invocation of the 
unsupported protocol. This effect can be obtained even though the data communication protocol 
feature is unsupported by the client. Tamagno et ah is silent in this regard. 

Due to the substantial differences between Tamagno et ah and the apparatus defined by 
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Claim 8, some of which are described above, withdrawal of this rejection is respectfully requested 
with respect to claim 8 and claims 9-13 due to their direct or indirect dependency from claim 8. 

The 35 U.S.C. S103 Rejection 

Claim 14 was rejected under 35 U.S.C. § 103(a) as being unpatentable over Tamagno et al 
(U.S. Patent Publication No. 2004/0215471 Al) in view of Ip (U.S. Patent No. 6,018,787). This 
rejection is respectfully traversed and withdrawal thereof is requested. 

Claim 8 recites: 

A host interface device apparatus for controlling data transfers between the host interface 
device and a client interface device, comprising: 

a) host logic configured to cause transmission to the client of a control data sequence 
predetermined to invoke a first data communication protocol response from the client; 

b) a triggering host signal indicating a need for invocation of a different second data 
communication protocol from the client; and 

c) host logic configured to cause transmission to the client of the predetermined data 
sequence to invoke the first data communication protocol response from the client in 
response to both of 

i) a host need to invoke the first protocol, and 

ii) the triggering host signal for the second protocol in an absence of (c)(i). 
Claim 14 indirectly depends from claim 8. 

As described above, Tamagno et al do not teach each and every step of rejected claim 8. 
The same applies to claim 14 due to its indirect dependency from claim 8. The Examiner's 
combination of Ip with Tamagno et al does not overcome the substantial deficiencies of Tamagno et 
al in that regard. Claim 14 recites a "first data communication protocol" and a "different second 
data communication protocol" for communications between a host and client. It is directed toward 
communication between a single pair of devices using two different protocols and host logic 
associated with the same. In contrast, Tamagno et al do not teach or suggest such an apparatus. 
Rather, Tamagno et al describe use of two protocols for communicating between three devices (/. e. , 
a smart card, a smart card reader, and a personal computer) - one protocol for communications 
between the smart card and smart card reader and the other protocol for communications between the 
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smart card reader and the personal computer. Similarly, Ip does not teach or suggest such apparatus. 

Thus, withdrawal of this rejection is respectfully requested. 

Prior Art Not Relied Upon But Made of Record 

It is believed that the document, U.S. Patent No. 6,023,684 (Pearson), is no more relevant to 
patentability of the presently claimed invention than those documents discussed elsewhere herein. 
The differences between Pearson and the present claims are not discussed in this paper based on 
their significance and due to the fact that Pearson has not been relied upon in rejecting any of the 
pending claims as being unpatentable. Applicants reserve the right, however, to provide detailed 
arguments in that regard should Pearson be relied upon as supporting a position that the claims are 
unpatentable in the future. 



It is respectfully submitted that the amendment and remarks set forth above overcome each 
objection and each grounds of rejection set forth by the Examiner. As such, the Examiner is 
respectfully requested to reconsider the application, to withdraw all previous rejections, and, barring 
the discovery of new grounds for rejection, to promptly issue a Notice of Allowance of all pending 
claims. 

The Commissioner is authorized to construe this paper as including a petition to extend the 
period for response by the number of months necessary to make this paper timely filed. Fees or 
deficiencies required to cause the response to be complete and timely filed may be charged, and any 
overpayments should be credited, to our Deposit Account No. 50-0490. 
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